Advances in semi-conductor processing and logic design have permitted an increase in the amount of logic that may be present on integrated circuit devices. As a result, computer system configurations have evolved from a single or multiple integrated circuits in a system to multiple cores and multiple threads present on individual integrated circuits. A processor or integrated circuit typically comprises a single processor die, where the processor die may include any number of cores or threads, which are often viewed from the perspective of software as logical processors. A core or thread is may also be referred to as a resource, such as a processing resource.
The ever increasing number of resources on integrated circuits enables more software threads to be executed simultaneously. However, the increase in the number of software threads that may be executed concurrently have created problems with synchronizing data shared among the software threads. One common solution to accessing shared data in multiple core or multiple logical processor systems comprises the use of locks to guarantee mutual exclusion across multiple accesses to shared data. However, the ever increasing ability to execute multiple software threads potentially results in false contention and a serialization of execution.
For example, consider a hash table holding shared data. With a lock system, a programmer may lock the entire hash table, allowing one thread to access the entire hash table. However, throughput and performance of other threads is potentially adversely affected, as they are unable to access any entries in the hash table, until the lock is released. Alternatively, each entry in the hash table may be locked. However, this increases programming complexity, as programmers have to account for more locks within a hash table.
Another data synchronization technique includes the use of transactional memory (TM). Often transactional execution includes speculatively executing a grouping of a plurality of micro-operations, operations, or instructions. In the example above, both threads execute within the hash table, and their accesses are monitored/tracked. If both threads access/alter the same entry, one of the transactions may be aborted to resolve the conflict.
During execution of a transaction a function call may be made. During execution of the function within the transaction address-taken local variables are buffered in a write buffer or logged in a write log. When returning from the function, certain local variables from the function become dead data. Upon exiting the transaction through an abort or commit, the transaction updates, which are either stored in a write log or write buffer, are written back to a program stack. However, the abort or commit function is potentially using data located in the program stack for local variables as well. Consequently, the updates of the program stack with the write logged/buffered data potentially corrupts local data elements for the abort or commit function.